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Cross References to Related Patent Applications 

This patent application is related to U.S. Patent Applications, Docket No. 944- 
001.103-4, and Docket No. 944-001.103-6, both assigned to the assignee of the present 
patent application and filed on even date herewith. 

Field of the Invention 

The present invention relates generally to multimedia streaming and, more 
particularly, to signaling of streaming quality adaptation and control mechanism. 

Background of the Invention 

In a multimedia streaming service, there are three participants involved: a 
streaming server, a streaming client and an underlying network which provides the 
connectivity between the server and the client. The server provides the functionality to 
deliver the multimedia streaming content to the client. For that purpose, the client and 
server communicate with each other over the network regarding the methods of capability 
exchange, content delivery method negotiation, content delivery control, and so forth. 
Such information exchange can be carried out via well-defined network protocols. 

For a multimedia streaming session to be set up and started successfully, the 
server and the client need to support a minimal set of protocols, which are selected as 
standard protocols by the service. An example of such a service can be found in 3GPP 
TS 26.234 V5.1.0, "Transparent End-to-End Packet Switched Streaming Service (PSS); 
Protocols and Codecs (Release 5)", June 2002, hereafter referred to as TS 26.234). 
Furthermore, in order for a service to be successful from the data delivery and playback 
performance point of view, the data delivery control mechanisms in the service must also 
be well-defined. Such mechanisms are used to adapt the data delivery process in order to 
cause the changes of behavior in the underlying network characteristics. 
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Three possible adaptation processes based on the decisive control location of the 
adaptation mechanisms or capabilities are as follows: 

Client-Driven Adaptation 
5 The client has control of the adaptation functionality or capability and makes the 

necessary decisions for adaptation. The decisions are based on information gathered from 
the network, the server, or other sources of information within the service definition. 

Server-Driven Adaptation 
10 The server has control of the adaptation functionality or capability and makes the 

necessary decisions for adaptation. The decisions are based on information gathered from 
the network, the client, or other sources of information within the service definition. 

Cooperative Adaptation 
15 Control of the adaptation functionality or capability is distributed between the 

server and the client. Both the server and the client can take actions for adaptation based 
on the information gathered from the network, the server, the client, or other sources of 
information within the service definition. 

20 Within the service context, there may be more than one adaptation mechanism or 

capability defined within the context of each of the above-mentioned adaptation 
processes. It may be the case that each of these adaptation mechanisms or capabilities is 
standardized within the service, but kept optional for a server or client to implement. 
Therefore, there is a certain need for a capability identification mechanism to 

25 identify the supported adaptation mechanisms or capabilities and an adaptation capability 
signaling and negotiation mechanism for the server and client to agree on the usage of a 
particular set of adaptation mechanisms or capabilities defined within the service context. 

In prior art, Annex G of 3G PSS (Rel.5) defines a signaling mechanism, which 
can be used to signal the usage and support parameters, but this is not a complete 

30 solution. 



Summary of the Invention 

The present invention provides a method of signaling and negotiation between a 
client and a server in a multimedia streaming service regarding the adaptation of the data 
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delivery process. The method can be carried out using a capability exchange mechanism, 
or using a multimedia streaming control protocol. The method of signaling and 
negotiation, according to the present invention, can be implemented in AVPF (Extended 
RTP profile for PTCP-based feedback) usage in a particular 3G PSS session; RTP 
5 retransmission payload format usage in a particular 3G PSS session; and SRTP usage in a 
particular 3G PSS session. 

The method, according to the present invention, can be carried out when the 
Multimedia Streaming Service has well-defined and/or standardized adaptation processes, 
and each adaptation process is composed of well-defined and/or standardized 
10 mechanisms, which are tools to render the adaptation functionality or capability 

functional. Furthermore, each adaptation mechanism or capability has an attribute that is 
well-defined and/or standardized within the service context, or well-known between the 
server and the client. 

Accordingly, the present invention provide a method for signaling and negotiation 
1 5 between a client and a server in a multimedia streaming service, wherein a plurality of 
adaptation mechanisms or capabilities for use in the service for data delivery are 
supported by the client, each adaptation mechanism or capability having an attribute. The 
method comprises: 

the client providing information indicative of the attributes defining the adaptation 
20 mechanisms or capabilities that are supported by the client; 

the server selecting one or more of the attributes based on the provided 
information; and 

the server providing further information indicative of the selected attributes so as 
to allow the client to know the one or more adaptation mechanisms or capabilities defined 
25 by the one or more attributes selected by the server. 

According to the present invention, the client provides the information via a 
capability exchange mechanism, or via a multimedia streaming control protocol. 

Alternatively, the method comprises: 

providing by one of the two parties to the other of the two parties information 
30 indicative of one or more attributes defining one or more of the adaptation mechanisms or 
capabilities; and 

conveying a message from said other party to said party, in response to the 
information, acknowledging supporting of said one or more adaptation mechanisms or 
capabilities. 
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Either the client or the server can initiate the negotiation. If the client initiates the 
negotiation, the client provides a plurality of attributes to the server; and the server selects 
one or more of the provided attributes based on the provided information for 
acknowledging the support. 

5 

Brief Description of the Drawing 

Figure 1 shows a declaration by a client as part of the signaling and negotiation 
process, according to the present invention. 

Figure 2 shows the SDP description sent by the server to indicate the selected 
10 attributes to the client, according to the present invention. 

Figure 3 shows the SDP description in an RTSP message sent by the server. 

Figure 4 shows an RTSP DESCRIBE response sent by the server. 

Figure 5 shows a declaration by the client as part of the signaling and negotiation 
process, according to another embodiment of the present invention. 
15 Figure 6 shows the SDP description sent by the server to indicate the selected 

attributes to the client, according to the other embodiment of the present invention. 

Figure 7 shows the SDP description in an RTSP message sent by the server. 

Figure 8 shows an RTSP DESCRIBE response sent by the server. 

Figure 9 shows a declaration by the client as part of the signaling and negotiation 
20 process, according to yet another embodiment of the present invention. 

Figure 10 shows the SDP description sent by the server to indicate the selected 
attributes to the client, according to the present invention. 

Figure 1 1 shows the SDP description in an RTSP message sent by the server. 

Figure 12 shows an RTSP DESCRIBE response sent by the server. 
25 Figure 13 is a flowchart illustrating the method of signaling and negotiation 

between a client and a server regarding the adaptation of a data delivery process, wherein 
the client initiates the negotiation. 

Figure 14 is a flowchart illustrating the method of signaling and negotiation 
wherein the server initiates the negotiation. 
30 Detailed Description of the Invention 

The method of signaling and negotiation between a client and a server in a 
multimedia streaming service regarding the adaptation of the data delivery process, 
according to the present invention, can be carried out via a capability exchange 
mechanism or via a multimedia stream control protocol. The adaptation of the data 
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delivery process is based on one or more attributes of one or more adaptation mechanisms 
or capabilities, which are used to determine the adaptation processes in a Multimedia 
Streaming Service. 

When the signaling and negotiation is carried out via a capability exchange 
5 mechanism, the procedure is described as follows: 

The client declares in its capability profile defined for a capability exchange 
mechanism the attributes of the adaptation mechanisms or capabilities 
implemented by the client; 
The server obtains the capability profile; 

10 As the server knows which adaptation mechanisms or capabilities are 

implemented by the client, the server selects a subset of the attributes that do 
not conflict with the adaptation processes. According to the selected subset of 
attributes, the server tailors the multimedia session description and declares 
the session description to the client; and 

15 - Based on the session description, the client knows the adaptation mechanism 

or capability selection carried out by the server for the particular multimedia 
session. The client accepts the adaptation mechanisms or capabilities declared 
in the session description by default, because the declared description contains 
a subset of the attributes or adaptation mechanism capabilities declared by the 

20 client. 

When the signaling and negotiation is carried out via a multimedia streaming 
control protocol, the procedure is described as follows: 

The client includes the attributes of the adaptation mechanism or capability 
25 implemented by the client in the Multimedia Streaming Control Protocol 

defined for the control of the streaming session; 
- Based on those attributes, the server knows which adaptation mechanisms or 
capabilities are implemented or required by the client. The server selects a 
subset of attributes that do not conflict with the adaptation processes and 
30 signals to the client the selected or non-selected attributes. Depending on the 

current phase of the control communication, the server may tailor the 
multimedia session description according to the selected attributes and declare 
the session description to the client; and 



5 



PATENT 
944-001.103-5 

Based on the response from the server, the client knows which attributes are 
selected by the server. The client accepts by default the adaptation 
mechanisms or capabilities defined by the attributes selected by the server, 
because the selected adaptation mechanisms or capabilities are a subset of the 
5 adaptation mechanisms or capabilities declared by the client. 

The method of signaling and negotiation, according to the present invention, can 
be implemented in the multimedia streaming service based on TS 26.234 or later releases. 
The implementation covers the definition, signaling and negotiation of the following 
mechanisms: 

an AVPF usage in a particular 3G PSS session (see, for example, IETF draft- 
ietf-avt-rtcp-feedback-04: "Extended RTP profile for RTCP-based Feedback 
(RTP/ AVPF)" Ott et al., 2002, hereafter referred to as draft-avpf-04); 
an RTP Retransmission Payload Format usage in a particular 3G PSS session 
(see, for example, IETF dradt-ietf-avt-rpt-retransmission-05: "RTP 
Retransmission Payload Format", Rey et al., 2002, hereafter referred to as 
draft-retransmission-0S)\ and 

an SPTP usage in a particular 3G PSS session (see, for example, IETF draft- 
ietf-avt-srtp-05: "The Secure Real-time Transport Protocol", Baugher et al., 
2002, hereafter referred to as draft-srtp-05). 

L AVPF usage in a particular 3G PSS session 

If AVPF, as defined in draft-avpf-04 is supported by the client, and the client 
signals the AVPF support, then the server may use any combination of AVPF features as 
25 defined in draft-avpf-04 in the adaptation process. The client may also signal each 
supportable feature of AVPF (e.g., immediate feedback mode, early RTCP packet 
support, etc.) separately, if there's a well-defined mechanism identifier for that feature. 

Let the attribute "AVPFSupport" be defined in the RDF (Resource Description 
Framework) Schema vocabulary to signal the support of AVPF defined in draft-avpf-04 
30 for audio and video media. 

Let the attribute "UnSupportedAdaptationSupport" be defined in the RDF Schema 
vocabulary as an adaptation mechanism or capability, which is supported by the client, 
but not by the server. 

6 



10 



15 



20 



PATENT 
944-001.103-5 

Let the attribute "SupportedAdaptationSupport" be defined in the RDF Schema 
vocabulary as an adaptation mechanism or capability, which is also supported by the 
server. 

Let "x-avpfsupport" be a well-defined SDP (Session Description Protocol) 
5 attribute, which is included in the audio and video (or the session-level for usage in both 
media types) media section of the SDP when AVPF is supported. 

Let "x-unsupportedadaptationsupport" be a well-defined SDP attribute, which is 
included in the SDP (session or media level) when supported. 

Let "x-supportedadaptationsupport" be a well-defined SDP attribute, which is 
10 included in the SDP (session or media level) when supported. 

A. Signalling and negotiation via a possible capacity exchange mechanism: 

The client sends an RTSP DESCRIBE request to the server with a URI pointing to 
the client capability information residing in a capability exchange server. 

15 - The server fetches the capability declaration of the client from the capability 

exchange server. The declaration includes a part for the client-side streaming capabilities, 
as shown in Figure 1 . 

The bold lines in the declaration represent the adaptation mechanism support 
capabilities of the client. It should be noted that when an attribute value is TRUE, the 

20 mechanism or capability is supported by the client. Conversely, when the attribute value 
is FALSE, the mechanism or capability is not supported by the client. For example, if the 
attribute AVPFSupport is TRUE, it declares that the client has the AVPF support for audio 
and video media components in a particular session. 

Seeing this capability, the server tailors the SDP description to be sent to the client 

25 including the AVPF capability and the SupportedAdaptationSupport capability. The SDP 
description is shown in Figure 2. The server does not include the SDP attributes based on 
the UnsupportedAdaptationSupport, because it does not have support for it. The bold lines 
in the SDP description indicate the usage of the AVPF and the support for 
SupportedAdaptationSupport. 

30 - By receiving this SDP description, the client knows that AVPF will be used for 
the video component, but not for the audio component. It is also possible that AVPF be 
used for both audio and video media components. In such a case, "a=x-avpf support" 
would be a session-level SDP attribute. Client also understands that 
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UnsupportedAptationSupport will not be used and SupportedAdaptationSupport 

mechanism or capability will be used for both audio and video media. 

B. Signalling and negotiation via a possible Multimedia Streaming Control Protocol: 
5 In 3G PSS, RTSP protocol is used to control the multimedia session. 

Let "x-avpfsupport" be a well-defined RTSP option tag, which indicates AVPF 
support on the client. 

Let "x-unsupportedadaptationsupport" be a well-defined RTSP option tag, which is 
signalled in the RTSP message when supported by the client. It is assumed that the 
10 mechanism represented by this tag is not supported by the server. 

Let "x-supportedadaptationsupport" be a well-defined RTSP option tag, which is 
signalled in the RTSP message when supported by the client. 

The client is assumed to know the RTSP URL for the multimedia session. 

15 - The client sends a DESCRIBE request with the selection of preferred adaptation 
mechanisms or capabilities: 

Client->Server: 

DESCRIBE rtsp://foo/twister RTSP/1.0 
20 CSeq: 1 

Require: x-avpfsupport, x-unsupportedadaptationsupport, x- 
supportedadaptationsupport 

The client uses the RTSP Require request header to signal the supported 
25 mechanisms or capabilites. 

In order for the server to successfully tailor the SDP according to the mechanisms 
or capabilities supported by the client, the client signals the mechanisms or capabilities 
supported in an RTSP request prior to or at RTSP DESCRIBE method. 
30 - The server checks the RTSP request and sees that it can use x-avpfsupport and x- 

supportedadaptationsupport, but not x-unsupportedadaptationsupport. 

The server has two possible ways to respond: 

35 ALTERNATIVE 1: 
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Server sends an RTSP 551 "Option Not Supported" Response, including the 
unsupported mechanisms and capabilities in the message body: 

Server->Client 
5 RTSP/1 .0 551 Option not supported 

CSeq: 1 

Unsupported: x-unsupportedadaptationsupport 

Client issues another DESCRIBE request with only the supported mechanisms or 
10 capabilities: 

Client->Server : 

DESCRIBE rtsp://foo/twister RTSP/1 .0 
CSeq: 2 

15 Require: x-avpfsupport, x-supportedadaptationsupport 

Server responds with an RTSP 200 OK message, also containing SDP description 
as shown in Figure 3. 

ALTERNATIVE 2: 

Server sends a RTSP DESCRIBE response, containing unsupported 
mechanism/capability information without an RTSP 551 status response. The RTSP 
DESCRIBE response is shown in Figure 4. 

Server uses RTSP Unsupported response header to signal the unsupported 
mechanism or the adaptation mechanisms or capabilities that are not possible to use for 
the particular session, and uses the appropriate SDP attributes to signal the usage of the 
selected adaptation mechanisms or capabilities. 

When the client receives the DESCRIBE response with the SDP description, it 
knows which set of adaptation mechanisms or capabilities are selected for usage in this 
particular session. 

In the case that the client receives the SDP description from another source, e.g. 
via MMS, the client can analyze the SDP description and find out the RTSP session URL. 
Then, it can send an RTSP DESCRIBE request to signal and negotiate the adaptation 
mechanisms or capabilities. The client can tailor the set of adaptation mechanisms or 
capabilities by analyzing the MMS retrieved SDP description beforehand. This solves the 
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confusion on the server side, because the server does not exactly know the content of the 
SDP description in such a usage scenario. 

H RTP Retransmission Payload Format usage in a particular 3G PSS session 
5 Let the attribute "RtxSupport" be defined in the RDF Schema vocabulary to signal 

the usage of the RTP retransmission mechanism defined in draft-retransmission for audio 
and video media. RTX Support is automatically defined AVPF support on the client side. 

Let the attribute "UnSupportedAdaptationSupport" be defined in the RDF Schema 
vocabulary as an adaptation mechanism or capability, which is not supported by the 
10 server, but the client. 

Let the attribute "SupportedAdaptationSupport" be defined in the RDF Schema 
vocabulary as an adaptation mechanism or capability, which is also supported by the 
server. 

Let "x-rtxsupport" be a well-defined SDP attribute which is included in the audio 
15 and video (or the session-level for usage in both media types) media section of the SDP 
when RTP retransmission payload format is supported. 

Let "x-unsupportedadaptationsupport" be a well-defined SDP attribute which is 
included in the SDP (session or media level) when supported. 

Let "x-supportedadaptationsupport" be a well-defined SDP attribute which is 
20 included in the SDP (session or media level) when supported. 

A. Signalling and Negotiation via a Possible Capability Exchange Mechanism 

The client sends an RTSP DESCRIBE request to the server with a URI pointing to 

the client capability information residing in a capability exchange server. 
25 - The server fetches the capability declaration of the client from the capability 

exchange server. The declaration includes a part for the client-side streaming capabilities, 

as shown in Figure 5. 

The bold lines in the declaration represent the adaptation mechanism support 

capabilities of the client. RtxSupport, when TRUE, declares that the client has the RTP 
30 retransmission payload format support for audio and video media components in a 

particular session. 

Seeing this capability, the server tailors the SDP description to be sent to the 
client, including the RTP Retransmission capability and the SupportedAdaptationSupport 
capability. The SDP description is shown in Figure 6. The server does not include the 

10 
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SDP attributes based on the UnsupportedAdaptationSupport, because it does not have 
support for it. The bold lines in the SDP description indicate the usage of the RTP 
Retransmission payload format and the support for Supported AdaptationSupport. 

By receiving this SDP description, the client knows that RTP retransmission will 
be used for the video component, but not for the audio component. It also understands 
that UnsupportedadAptationSupport will not be used and SupportedAptationSupport 
mechanism or capability will be used for both audio and video media. 

B. Signalling and Negotiation via a possible Multimedia Streaming Control Protocol 

In 3G PSS, RTSP protocol is used to control the multimedia session. 

Let "x-rtxsupport" be a well-defined RTSP option tag, which indicates RTP 
retransmission payload format is supported by the client. 

Let "x-unsupportedadaptationsupport" be a well-defined RTSP option tag, which is 
signalled in the RTSP message when supported by the client. Assume that the mechanism 
or capability represented by this tag is not supported by the server. 

Let "x-supportedadaptationsupport" be a well-defined RTSP option tag, which is 
signalled in the RTSP message when supported by the client. 

The client is assumed to know the RTSP URL for the multimedia session. 

The client sends a DESCRIBE request with the selection of preferred adaptation 
mechanisms or capabilities: 

Client->Server : 

DESCRIBE rtsp://foo/twister RTSP/1.0 
CSeq: 1 

Require: x-rtxsupport, x-unsupportedadaptationsupport, x- 
supportedadaptationsupport 

The client uses the RTSP Require request header to signal the supported 
adaptation mechanisms or capabilities. 

In order for the server to successfully tailor the SDP according to the adaptation 
mechanisms or capabilities supported by the client, the client signals the adaptation 
mechanisms or capabilities supported in an RTSP request prior to or at RTSP DESCRIBE 
method. 



11 



PATENT 
944-001.103-5 

The server checks the RTSP request and sees that it can use x-rtpsupport and x- 
supportedadaptationsupport, but not use x-unsupportedadaptationsupport. 

The server has two possible ways to respond: 

ALTERNATIVE 1: 

Server sends RTSP 551 "Option Not Supported" Response, including the 
unsupported mechanisms or capabilities in the message body. 

Server->Client 

RTSP/1 .0 551 Option not supported 
CSeq: 1 

Unsupported: x-unsupportedadaptationsupport 

Client issues another DESCRIBE request with only the supported mechanisms or 
capabilities: 

Client->Server : 

DESCRIBE rtsp://foo/twister RTSP/1 .0 
CSeq: 2 

Require: x-rtxsupport, x-supportedadaptationsupport 

Server responds with RTSP 200 OK message, also containing an SDP description 
as shown in Figure 7. 

ALTERNATIVE 2: 

Server sends an RTSP DESCRIBE response, containing unsupported 
mechanism/capability information without RTSP 551 status response. The RTSP 
DESCRIBE response is shown in Figure 8. 

The server uses RTSP Unsupported response header to signal the unsupported 
mechanism or the adaptation mechanisms or capabilities that are not possible to use for 
the particular session, and uses the appropriate SDP attributes to signal the usage of the 
selected adaptation mechanisms or capabilities. 
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When client receives the DESCRIBE response with the SDP description, it knows 
which set of adaptation mechanisms or capabilities are selected for usage in this particular 
session. 

In the case that the client receives the SDP description from another source, e.g. 
5 via MMS, the client analyzes the SDP description and find out the RTSP session URL. 
Then, it sends an RTSP DESCRIBE request to signal and negotiate the adaptation 
mechanisms or capabilities. The client can tailor the set of adaptation mechanisms or 
capabilities by analyzing the MMS retrieved SDP description beforehand. This solves the 
confusion on the server side, because the server does not exactly know the content of the 
10 SDP description in such a usage scenario. 

III. SRTP usage in a particular 3G PSS session 

Let the attribute "SRTPSupport" be defined in the RDF Schema vocabulary to 
signal the support of SRTP defined in draft-srtp-05 for audio and video media. 
15 Let the attribute "Unsupported AdaptationSupport" be defined in the RDF Schema 

vocabulary as an adaptation mechanism or capability, which is supported by the client, 
but not by the server. 

Let the attribute "SupportedAdaptationSupport" be defined in the RDF Schema 
vocabulary as an adaptation mechanism or capability, which is also supported by the 
20 server. 

Let "x-srtpsupport" be a well-defined SDP attribute which is included in the audio 
and video (or the session-level for usage in both media types) media section of the SDP 
when SRTP is supported. 

Let "x-unsupportedadaptationsupport" be a well-defined SDP attribute which is 
25 included in the SDP (session or media level) when supported. 

Let "x-supportedadaptationsupport" be a well-defined SDP attribute which is 
included in the SDP (session or media level) when supported. 

A. Signalling and Negotiation via a Possible Capability Exchange Mechanism 
30 - The client sends an RTSP DESCRIBE request to the server with a URI pointing to 
the client capability information residing in a capability exchange server. 

The server fetches the capability declaration of the client from the capability 
exchange server. The declaration includes a part for the client-side streaming capabilities, 
as shown in Figure 9. The bold lines in the declaration represent the adaptation 
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mechanism support capabilities of the client. SRTPSupport, when TRUE, declares that 
the client has the SRTP support for audio and video media components in a particular 
session. 

Seeing this capability, the server tailors the SDP description to be sent to the client 
including the SRTP capability and the SupportedAdaptationSupport capability. The SDP 
description is shown in Figure 10. The server does not include the SDP attributes based 
on the UnsupportedAdaptationSupport, because it does not have support for it. 

The bold lines in the SDP description indicate the usage of the SRTP and the 
support for SupportedAdaptationSupport. 

By receiving this SDP description, the client knows that SRTP will be used for 
video and audio components. Client also understands that UnsupportedadAptationSupport 
is not going to be used and Supported AptationSupport mechanism or capability will be 
used for both audio and video media. 

B. Signalling and Negotiation via a possible Multimedia Streaming Control Protocol 

In 3G PSS, RTSP protocol is used to control the multimedia session. 

Let "x-srtpsupport" be a well-defined RTSP option tag, which indicates SRTP 
support on the client. 

Let "x-unsupportedadaptationsupport" be a well-defined RTSP option tag, which is 
signalled in the RTSP message when supported by the client. Assume that the mechanism 
or capability represented by this tag is not supported by the server. 

Let "x-supportedadaptationsupport" be a well-defined RTSP option tag, which is 
signalled in the RTSP message when supported by the client. 

The client is assumed to know the RTSP URL for the multimedia session. 

The client sends a DESCRIBE request with the selection of preferred adaptation 
mechanisms or capabilities: 

Client->Server : 

DESCRIBE rtsp://foo/twister RTSP/1.0 
CSeq: 1 

Require: x-srtpsupport, x-unsupportedadaptationsupport, x- 
supportedadaptationsupport 
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The client uses the RTSP Require request header to signal the supported 
mechanisms or capabilities. 

In order for the server to successfully tailor the SDP according to the mechanisms 
or capabilities supported by the client, the client signals the mechanisms or capabilities 
supported in an RTSP request prior to or at RTSP DESCRIBE method. 

The server checks the RTSP request and sees that it can use x-srtpsupport and x- 
supportedadaptationsupport, but not x-unsupportedadaptationsupport. 

The server has two possible ways to respond: 

ALTERNATIVE 1: 

Server sends RTSP 551 "Option Not Supported" Response, including the 
unsupported mechanisms or capabilities in the message body. 

Server->Client 

RTSP/1 .0 551 Option not supported 
CSeq: 1 

Unsupported: x-unsupportedadaptationsupport 

Client issues another DESCRIBE request with only the supported mechanisms or 
capabilities: 

Client->Server : 

DESCRIBE rtsp://foo/twister RTSP/1 .0 
CSeq: 2 

Require: x-srtpsupport, x-supportedadaptationsupport 

Server responds with RTSP 200 OK message, also containing an SDP description 
as shown in Figure 1 1 . 

ALTERNATIVE 2: 

Server sends an RTSP DESCRIBE response, containing unsupported 
mechanism/capabilitiy information without RTSP 551 status response. The RTSP 
DESCRIBE response is shown in Figure 12. 
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The server uses RTSP Unsupported response header to signal the unsupported 
mechanism or the adaptation mechanisms or capabilities that are not possible to use for 
the particular session, and uses the appropriate SDP attributes to signal the usage of the 
selected adaptation mechanisms or capabilities. 
5 - When client receives the DESCRIBE response with the SDP description, it knows 
which set of adaptation mechanisms or capabilities are selected for usage in this particular 
session. 

In the case that the client receives the SDP description from another source, e.g. 
via MMS, the client analyzes the SDP description and find out the RTSP session URL. 
10 Then, it sends an RTSP DESCRIBE request to signal and negotiate the adaptation 

mechanisms or capabilities. The client can tailor the set of adaptation mechanisms or 
capabilities by analysing the MMS retrieved SDP description beforehand. This solves the 
confusion on the server side, because the server does not exactly know the content of the 
SDP description in such a usage scenario. 

15 

In sum, the present invention provides a method of signaling and negotiation 
between a client and a server in a multimedia streaming service system regarding the 
adaptation of a data delivery process. The procedure for the signaling and negotiation can 
be illustrated by Figure 13. As shown in the flowchart in Figure 13, in order to negotiate 

20 an adaptation mechanism or capability, the client signals to the server a plurality of 
attributes to the client at step 110. These attributes are those of the adaptation 
mechanisms or capabilities implemented by the client. The attributes are included either 
in client's capability profile defined for a capability exchange mechanism, or in the 
multimedia streaming control protocol defined for the control of the streaming session. 

25 At step 120, the server obtains the attributes from the capability profile or the multimedia 
streaming control protocol, and selects a subset of these attributes. Based on the selected 
attributes, the server tailors a multimedia session description and sends the description to 
the client at step 130. Based on the session description, the client knows the attributes 
selected by the server. At step 140, the client accepts the adaptation mechanisms or 

30 capabilities defined by the selected attributes at default. The signaling and negotiation 
method, according to the present invention, can be implemented in an AVPT usage, an 
RTP Retransmission Payload Format usage or an SPTP usage in a particular 3G PSS 
session. 
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It should be noted that the method of signaling and negotiation, according to the 
present invention, can also be initiated by the server, as illustrated in the flowchart shown 
in Figure 14. As shown, the server indicates to the client, at step 210, the adaptation 
mechanism or capability without client's initiation. In this case, there is no indication of 
5 the adaptation mechanism or capability from the client side, but from the server side. 

After obtaining the indication from the server, the client uses a well-defined attribute in 
the RSTP response to indicate, at step 220, its support for that capability to the server. 

Thus, although the invention has been described with respect to a preferred 
embodiment thereof, it will be understood by those skilled in the art that the foregoing 
10 and various other changes, omissions and deviations in the form and detail thereof may be 
made without departing from the scope of this invention. 
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